Revisiting the Core Ontology and Problem in Requirements Engineering

In their seminal paper in the ACM Transactions on Software Engineering and Methodology, Zave and Jackson established a core ontology for Requirements Engineering (RE) and used it to formulate the "requirements problem", thereby defining what it means to successfully complete RE. Given that stakeholders of the system-to-be communicate the information needed to perform RE, we show that Zave and Jackson's ontology is incomplete. It does not cover all types of basic concerns that the stakeholders communicate. These include beliefs, desires, intentions, and attitudes. In response, we propose a core ontology that covers these concerns and is grounded in sound conceptual foundations resting on a foundational ontology. The new core ontology for RE leads to a new formulation of the requirements problem that extends Zave and Jackson's formulation. We thereby establish new standards for what minimum information should be represented in RE languages and new criteria for determining whether RE has been successfully completed.Comment: Appears in the proceedings of the 16th IEEE International Requirements Engineering Conference, 2008 (RE'08). Best paper awar

The PSN tribe

AbstractThe paper reviews the history, premises, research results and applications of the Procedural Semantic Network (hereafter PSN) formalism and two of its descendants, Taxis and Telos. The primary goal for the PSN project was to develop a knowledge representation formalism which combined gracefully semantic networks and procedural representations. After an initial proposal which set out a framework for the integration of these two types of representations [1], a number of features were investigated, including the treatment of contexts, the declarative representation of slots and procedures and several others. In parallel, attempts were made to apply some of the representation ideas embodied in PSN to the task of developing suitable languages for the early stages of information system design. During these stages, the designer is concerned with understanding the problem at hand and then proceeding with the specification of an initial conceptual design of an information system that meets stated requirements. Taxis and Telos were the result of this effort. Their features are outlined, along with a rationale for the differences between the three formalisms

The Logic of Requirements

Requirements consist of (a) domain assumptions, (b) hard goals, (c) quality constraints, (d) possibly prioritized preferences. The very core of Requirements Engineering consists of the following problem: given a set of (a)-(d), generate specifications that fulfill hard goals and quality constraints, assuming that domain assumptions hold, and satisfy maximal sets of preferences. We are working towards tools that solve this problem for expressive modeling languages in terms of which one can represent domain assumptions, goals, etc. Such tools can be used as basis for exploring requirements by varying preferences and priorities, or weakening/strengthening goals

Theory of Regulatory Compliance for Requirements Engineering

Regulatory compliance is increasingly being addressed in the practice of requirements engineering as a main stream concern. This paper points out a gap in the theoretical foundations of regulatory compliance, and presents a theory that states (i) what it means for requirements to be compliant, (ii) the compliance problem, i.e., the problem that the engineer should resolve in order to verify whether requirements are compliant, and (iii) testable hypotheses (predictions) about how compliance of requirements is verified. The theory is instantiated by presenting a requirements engineering framework that implements its principles, and is exemplified on a real-world case study.Comment: 16 page